The present invention relates to data center management and file systems, and more specifically, this invention relates to locking at the record level of a record-oriented file structure to ensure data integrity when performing operations to data records.
File systems which allow direct and sequential accesses to data stored therein typically utilize a B+ tree structure which is a variation of the basic B tree structure with all terminal nodes thereof containing data records. The non-terminal nodes of the B+ tree structure are referred to as an index structure. The top of the B+ tree structure is a single node referred to as the root. The B+ tree structure is a balanced tree with all the terminal nodes at the same level such that all data records stored therein have the same or substantially the same search length. The effectiveness and the popularity of the B+ tree structure may be attributable to the shape of the tree. The B+ tree tends to be short and wide, referred to typically as “flat,” e.g., it has few hierarchical levels and many nodes at each level.
The B+ tree structure has become somewhat of a standard for organization of files. Many database systems (relational or otherwise) and general-purpose access methods, such as virtual storage access method (VSAM), are designed using the B+ tree structure. The VSAM includes some additional features over other typical access methods, such as key compression. For ease of discussion, and due to the fact that VSAM was one of the first commercial products in the world that used the B+ tree structure, VSAM terminology may be used in the descriptions provided, but the descriptions are not limited to VSAM alone, as any access method may be used in relation to a B+ tree structure.
Virtual storage access method (VSAM) is a disk file storage access method used in IBM z/OS environments. VSAM data sets include multiple records, and the data sets are of fixed or variable length, and are organized into fixed-size blocks called Control Intervals (CIs). The CIs are then organized into larger groups referred to as Control Areas (CAs). CIs are used as units of transfer between direct access storage devices (DASDs) and requesting systems such that a read request will read one complete CI. CAs are used as units of allocation, such that when a VSAM data set is defined, an integral number of CAs will be allocated for that VSAM data set.
With key sequenced data sets (KSDSs), the contents consist of the users data and a unique key (specified by the user) which is used to locate specific data records in the data set. Each record in a KSDS has one unique key. Entry sequenced data sets (ESDSs) on the other hand, only contain user data, and the user provides the relative byte address (RBA) of the location of the specific data records for the VSAM to locate. The VSAM data sets containing the user data are referred to as the “base” data sets. The following is an example of user data which could be located in a KSDS or ESDS. In this example, a base data set named “MY.BASE.DS” includes an account number, name, and address, where the account number is specified by the user as the unique key for the KSDS, as shown in Table 1.
TABLE 1MY.BASE.DSUnique Key Data FieldData FieldRBAAccount NumberNameAddress  01234John Smith13 Main St., San Jose, CA40965678Jane Doe26 First St., San Francisco, CA81929ABCJohn Smith111 Beach St., Santa Cruz, CA
In order to locate each of the three records in the above data set, the unique keys in the Account Number field may be used for a KSDS, and the RBA values for an ESDS.
VSAM also allows the user to locate the data records in the base data sets via different (or alternate) key fields than the base key. This is accomplished by defining another (alternate) KSDS which is built over the base data sets. The alternate KSDS is referred to as an Alternate Index (AIX). The base data set may be a KSDS or an ESDS. The record key in the base KSDS is called the primary key; the key in an AIX is an alternate key. For example, using the above base data set MY.BASE.DS as an example, two AIXs may be defined with separate alternate keys for the Name and Address fields, respectively. For each AIX, a Path entry is defined to relate the specific AIX to the base. For example, reference is made to Table 2.
TABLE 2Path EntriesPathnameAIX NameAIX Key FieldBase NameMY.PATH1MY.AIX1.DSNameMY.BASE.DSMY.PATH2MY.AIX2.DSAddressMY.BASE.DS
The contents of the AIX KSDS may include the following records in this example, as shown in Tables 3 and 4.
TABLE 3MY.AIX1.DSAlternate KeyRBA(s)John Smith  0, 8192Jane Doe4096
TABLE 4MY.AIX2.DSAlternate KeyRBA(s)13 Main St., San Jose, CA026 First St., San Francisco, CA4096111 Beach St., Santa Cruz, CA8192
The user may now access the data records in the base data set, MY.BASE.DS, via the path entries. For example, when using MY.PATH1, the user may supply the person's name and VSAM will return matching base records. If a name of ‘John Smith’ is provided, VSAM will return both of the John Smith records in the base data set. When using MY.PATH2, the user may supply an address, and VSAM will return any record matching the specified address. Whenever the base records are updated, added, and/or deleted, the AIX data sets are also updated. Together, the AIX data sets are referred to as the “upgrade set.” This is because the AIXs are updated together whenever the user updates the base records.
When VSAM updates the upgrade set, the entire set of KSDS AIXs are locked, allowing only one update to occur at a time. This lock is referred to as the “upgrade lock.” Holding an upgrade level lock results in severe performance problems whenever the base data set is modified. It would be beneficial to avoid these severe performance problems from occurring during updates to the upgrade set.
Some attempts have been made to address this issue, including using application logic to avoid the use of VSAM AIXs and using relational data base managers (e.g., DB2) to build tables relating the different fields in the user data. One disadvantage of the first approach is the cost to develop and maintain unique application code. Some disadvantages of using a relational database manager include the cost to migrate existing VSAM applications over to use the database manager, the processor and performance overhead associated with database managers, and requiring a different skill set for the user in order to operate the relational database manager.